A method of and devices for performing an over-the-air, ota, upgrade in a network of communicatively interconnected devices

ABSTRACT

A method ( 50 ) of and a server ( 19 ) and network node or client devices ( 3, 5 ) communicatively interconnected in a network ( 1 ) and arranged for over-the-air, OTA, data upgrade or update of client devices. In the event of a timeout ( 54 ) at the server ( 19 ) waiting for a response or request message from a selected OTA client ( 5 ) during an on-going OTA data upgrade, the OTA server ( 19 ) checks whether a network address change ( 51 ) of the selected OTA client ( 5 ) caused the OTA sewer to timeout.

TECHNICAL FIELD

The present disclosure generally relates to communication and control ina network of communicatively interconnected devices and, in particular,to over-the-air, OTA, upgrade or update of such devices in a large scalemesh network for use in various different applications for home, office,retail, hospitality and industry, for example.

BACKGROUND

Wireless Mesh Networks, WMNs, Wireless Personal Area Networks, WPANs, orin general communication networks comprised of a plurality ofcommunicatively interconnected devices, generally comprise multiplenetwork end nodes, network relay nodes, such as bridges, switches andother electric infrastructure devices and equipment. These node devicesare generally controlled by at least one network control or coordinatordevice, which may provide access to other networks and the Internet, forexample. Such a network control or coordinator device is genericallycalled a gateway device.

Examples of such communication devices are Customer-Premises Equipment,CPE, for example lighting devices having communication capabilities,Internet of Things, IoT, devices, and User Equipment, UE, for mobiletelephone and data communication. Network protocols for exchanging databy networked devices or nodes are generally available and known asZigBee™, Bluetooth™, as well as WiFi based protocols for wirelessnetworks, and wired bus networks such as DALI™ (Digital AddressableLighting Interface), DSI (Digital Serial Interface), DMX (DigitalMultiplex), and KNX (based systems).

The devices may communicate in either one of unicast mode and broadcastmode, using the Bluetooth Low Energy, BLE, mesh protocol or the ZigBeeprotocol, for example. A so-called combo-node device, with both ZigBeeand BLE connectivity, may operate as a temporal bridging node between amobile phone and a ZigBee-based lighting network, for example.

ZigBee networks represent a type of a low-power/low-cost wirelessnetworks which allow multi-hop communication among devices in a meshtopology. ZigBee devices offer reduced power consumption and cost,together with mesh networking capability, which make them suitable foruse in large-scale deployments. Typical application examples of ZigBeemesh networks include home automation, building automation, retailservices, smart energy, and wireless indoor lighting systems.

Commissioning of a network and its devices is a process in which a newnetwork is set up after installation and testing of the node devices,the gateway equipment and communication facilities of the network,according to design objectives or specifications, or when new device isadded to an existing network.

In a ZigBee network, for example, after commissioning of the network,every node broadcasts a device announce packet or message, comprisingaddress information of a respective node, such as its specific networkaddress and/or Media Access Control, MAC, address. The MAC address of adevice is a unique identifier assigned to a Network InterfaceController, NIC, of the device for communications at the data link layerof the network. With the device announce packet, the network gatewaydevice receives address information of a respective node in a networkfor communication and control purposes, also called the short address,and a network key may be obtained used to encrypt communication betweendevices in the network.

Smart electric or electronic devices, such as smart lighting devices ina ZigBee network, for example, usually have embedded software inside andoften need to upgrade or update their software for several times duringtheir whole life cycle. When the devices are installed in end users'sites, the most convenient way to upgrade or update them is to performover-the-air, OTA, upgrade. In ZigBee, the products' ZigBee channel maybe used to transmit the upgrade or update file or upgrade or update datato the devices, for example.

In practice, software upgrade or update is performed by an OTA serveroperatively connected to the network. Such an OTA server normallyresides in the gateway device of the network, however such a server mayalso operate remote from the network or gateway. Generally, in case ofan OTA upgrade, the network devices that require upgrade or update arecalled client devices. In the present description and the claims, theterm node device or in short node and client device or in short clientare generic for all the devices connected in a WMN, a WPAN, or anynetwork of communicatively interconnected communication devices.

In a ZigBee enabled network and devices, for example, prior to the startof an OTA, the OTA server builds an OTA list. The OTA list comprises thenetwork addresses of all candidate OTA clients that may require upgradeor update. Next, the OTA server broadcasts notification messages to theentire network, to notify all candidate OTA clients that an OTA is goingto start.

OTA starts in that the OTA server selects a respective OTA client bytransmitting a notification message based on the network address of thatOTA client. This notification message is preferably exchanged in aunicast mode of operation. After receiving the notification message, theaddressed OTA client requests data from the OTA server and the serverreplies the request with data blocks or data packages comprising theupgrade or update information. The OTA data blocks or packages areexchanged in a broadcast mode of operation, such that all other OTAclients can receive them too.

Once the respective OTA client has received all the upgrade or updatedata, the OTA client transmits a message informing the OTA server thatthe client has received all data of the upgrade file and the upgrade tothis OTA client is completed.

Next, the OTA server selects another OTA client by transmitting arespective notification message based on the network address of thisother OTA client. Because this other OTA client has already receivedmany data blocks or data packets from the broadcast of the upgrade dataor update data by the OTA server to the previous OTA client, the otherOTA client now only requests possible missing data blocks or datapackets from the OTA server. If this other client has no missing datablocks, it will immediately transmit a message informing the OTA serverthat the client has received all data of the upgrade file, and theupgrade to this OTA client is completed. As all the candidate OTAclients receive broadcasted OTA data, the OTA upgrade illustrated aboveis also called a fast OTA.

The OTA server repeats the transmission of a notification messageaddressed to all other candidate OTA clients from the list, one afterthe other, till the OTA server has received messages from all OTAclients informing the OTA server that all OTA clients have received theupgrade file, and the upgrade to all the OTA clients may be completed.

In a large ZigBee network, an OTA upgrade is usually performed in abroadcast data exchange mode, for the network as a whole. This, becausea step-by-step complete OTA for each single node or client device, inunicast mode for example, will take far too much time, such as up to1000 minutes, for example.

SUMMARY

During an ongoing upgrade, that is from the building of the list ofcandidate OTA clients by the OTA server, an OTA client's networkaddress, such as the ZigBee short address, may get changed. Such anetwork address change may be caused, for example, if there is anyaddress conflict between two node devices in a large network. Generally,after the client's network address changes, the client broadcasts itsnew or current network address in a device announce packet or message,as mentioned above in respect of the commissioning of the network andits devices. In particular in large scale networks, the OTA server maynot receive the message because exchange of messages by broadcasting inthe network is unreliable, especially when there is much OTA traffic inthe network, for example. Hence the OTA server is kept unknown of thenew short address and, eventually, the OTA upgrade process may fail, asthe OTA server and the OTA client are not able to communicate with eachother anymore. The OTA server may restart the OTA upgrade from thebeginning if OTA upgrade fails.

An OTA upgrade failure may also arise from a client or node reset duringan ongoing OTA upgrade. Then, the whole fast OTA will be delayed as thisnode will perform an OTA upgrade from the start, because the datapackets that are recorded during an OTA broadcast by the server inrespect of an other client may be lost as a consequence of the clientreset. Also in the case of a power interruption or power glitches that aclient may encounter, as the outdoor environment in a mesh network isquite tough, fast OTA upgrade may fail for a particular client orclients.

In general, any event that may cause a reboot of a client device cancause an OTA upgrade failure.

Accordingly, there is a need for handling an ongoing OTA upgrade orupdate of a client device in case of a failure of an OTA upgrade orupdate of a particular client or clients by a an OTA server in a networkof communicatively interconnected OTA clients.

The above mentioned and other objects are achieved, in a first aspect ofthe present disclosure, by a method of performing an over-the-air, OTA,upgrade by a server in a network of communicatively interconnectedclient devices, wherein the server transmits a network address queryingmessage if an ongoing OTA upgrade of a client device causes a timeout atthe server, and wherein the server resumes the OTA upgrade of the clientdevice after the server receives a network address reporting message ofthe client device comprising its current network address.

In accordance with the present disclosure, the OTA upgrade server, incase of a time out in an ongoing OTA upgrade, attempts to restore theOTA upgrade by checking whether a network address change of the clientserver may have caused failure of the OTA upgrade.

In case of a network address change of a client device, the clientdevice may not receive an OTA upgrade notification message transmittedby the server, notifying the ongoing OTA upgrade to the client device.Hence, the client device will not respond to the notification message byrequesting the server to transmit the data of the OTA upgrade, as aresult of which the server eventually experiences a timeout.

A network address change of a client device in an ongoing OTA upgrademay also cause a timeout in the server when receiving a request fortransmitting OTA upgrade data from a client device, as the networkaddress in the data request message does not match the network addressof the OTA upgrade notification message transmitted by the server. Inthat case the server assumes likewise not to receive a response from theclient device addressed by the OTA upgrade notification message, againcausing a timeout at the server.

In general, a timeout at the server in an ongoing upgrade of a clientmay occur if the server does not receive any expected message of theclient, based on the network address of the client, such as a request ormessage relating to the end of the upgrade, for example, when a clienthas received all upgrade data.

Hence, by querying, by the server, in accordance with the presentdisclosure, whether a network address change of the client device mayhave caused the timeout in the ongoing OTA upgrade, and resuming the OTAupgrade of the client device after the server receives a network addressreporting message of the client device comprising its current networkaddress, the OTA upgrade can be continued, and thereby time andresources can be saved compared to having to start the whole OTA upgradeprocess anew.

In accordance with the present disclosure, the network address queryingmessage transmitted by the server may comprise a Media Access Control,MAC, address or so-called IEEE address of the client device, as a uniqueidentification of the client device. It will be appreciated that anyidentification of a client device available to the server, other thanthe MAC or IEEE address of a client device, may be used to identify theclient device in the network address querying message.

To make sure that the network address querying message is received by aclient device, in accordance with an embodiment of the presentdisclosure, the said network address querying message is broadcasted bythe server in the network.

The network address querying message may be repeated by the server untila maximum number of repeats is exceeded, for example.

In an alternative embodiment in accordance with the present disclosure,the network address querying message transmitted by the server may alsotake the form of an inquiry message that commands or causes the node orclient devices in the network to announce their address information,such as used in commissioning of the network. From the MAC or IEEEaddress or any other unique identification of a client device includedwith the network address announce message, the server may identify aparticular client device, based on the client or node identificationinformation available to the server form commissioning of the network.

In an embodiment of the present disclosure, the server resumes the OTAupgrade of the client device by transmitting, based on the receivedcurrent network address of the client device, an OTA upgradenotification message notifying the OTA upgrade to the client device.

To ensure reliability of receipt of the OTA upgrade notification messageat the client device, the OTA upgrade notification message, based on thereceived current network address of the client device, is transmittedfrom the server to the client device in unicast transmission mode.

The client device, in a network of communicatively interconnected clientdevices, receiving a network address querying message from the server inan ongoing OTA upgrade, in accordance with a second aspect of thepresent disclosure, transmits in response to the network addressquerying message a network address reporting message in the networkcomprising the current network address of the client device.

When the network address querying message from the server comprises anidentification of a client, such as the MAC or IEEE address of theclient, only that client device receiving the network address queryingmessage the client identification of which matches the identification ofthe receiving client device will response to this querying message.

In the network address reporting message a client device may alsoinclude its identification, such as its MAC or IEEE identification, fromwhich the server based on the information received at commissioning ofthe network may link the network address received to the correct clientdevice.

To enhance the probability that the network address reporting messagewill be received by the OTA server, the network reporting message istransmitted in unicast mode.

To even further enhance receipt of the network address reporting messageby the OTA server, in an embodiment according to the present disclosure,the network address reporting message is repeated by the client deviceuntil a maximum number of repeats is exceeded.

In particular in a large network, comprising a plurality of node orclient devices, a network address change may occur at any stage of anongoing OTA upgrade, also when already data packets of OTA upgrade orupdate data have been transmitted by the server. A power outage, powerglitch or any other reset or reboot of a client device may cause lost ofreceived upgrade data at a client device.

In a further embodiment, the present disclosure provides to record, in aclient device, received OTA upgrade data packages and a current OTAupgrade status in a non-volatile storage, and wherein when the clientdevice resumes the OTA upgrade after receipt of an OTA upgradenotification message from the server notifying the OTA upgrade to theclient device.

In this manner, time and resources are saved by avoiding retransmittingof already transmitted data packets in an ongoing OTA upgrade, inparticular in a fast OTA upgrade or update, wherein candidate upgradeclients receive data packets transmitted by the server, although theserver effectively communicates in the OTA upgrade with another clientdevice, for example in ZigBee fast OTA upgrade.

In a third aspect of the present disclosure a server device is provided,arranged for performing an over-the-air, OTA, upgrade in a network ofcommunicatively interconnected client devices in accordance with themethod of the first aspect of the present disclosure.

In a fourth aspect, the present disclosure provides a client device,arranged for performing an over-the-air, OTA, upgrade in a network ofcommunicatively interconnected client devices in accordance with themethod of the second aspect of the present disclosure.

In a fifth aspect of the present disclosure there is provided a computerreadable computer program product, comprising computer program codeinstructions which, when run on a computer device, causes the computerdevice to perform the method of any of the first and second aspect of topresent disclosure. The computer program product may take the form of acomputer readable storage medium or non-transitory medium like a memorystick, data disc, and the like, and/or may be provided as a downloadsignal in a network, for example.

In a seventh aspect of the present disclosure there is a provided anelectric or electronic device, such as a lighting device, comprising aclient device according to the fourth aspect of the present disclosure.

These and other aspects of the disclosure will be apparent from andelucidated with reference to the embodiments described hereinafter.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates, schematically, a network of communicativelyinterconnected network node devices and a gateway device arranged foroperating as an over-the-air, OTA, server.

FIG. 2 illustrates, in a sequence diagram, an example of a method ofrequesting and reporting node device address announce messages in anetwork of communicatively interconnected network node devices.

FIG. 3 illustrates, in a sequence diagram, an example of a fast OTAprocedure in accordance with the ZigBee specification.

FIG. 4 illustrates, in a sequence diagram, an example of a fast OTAprocedure in accordance with the present disclosure.

FIG. 5 illustrates, in a sequence diagram, an other example of a fastOTA procedure in accordance with the present disclosure.

FIG. 6 illustrates, in a sequence diagram, a comprehensive example of aknown fast OTA upgrade in a ZigBee enabled communication network from anexternal source.

FIG. 7 illustrates, in a sequence diagram, the occurrence of a reset orpower outage of a node device in an ongoing fast OTA procedure inaccordance with the present disclosure.

FIG. 8 illustrates, in a flowchart diagram, an algorithm for restoringan interrupted OTA upgrade in case of a node device reset or poweroutage.

FIG. 9 illustrates, schematically, a circuit diagram of an embodiment ofan OTA server device in accordance with the present disclosure.

FIG. 10 illustrates, schematically, a circuit diagram of an embodimentof a node device in accordance with the present disclosure.

DETAILED DESCRIPTION

The present disclosure is detailed below with reference to a wirelessZigBee™ enabled network and ZigBee enabled devices. Those skilled in theart will appreciate that the present disclosure is not limited to ZigBeeoperated networks and devices, but is applicable to a wide variety ofnetworks of communicatively interconnected node devices, either partlywired and/or partly wireless, and arranged for exchange of softwareupgrade or update data of supplementary or peripheral electric orelectronic devices operatively connected to a node device in thenetwork.

Non-limited examples of other applicable transmission protocols areBluetooth™, Thread™, as well as WiFi based protocols and transmissionprotocols in accordance with a 3GPP standard, and wired bus networkssuch as DALI™ (Digital Addressable Lighting Interface), DSI (DigitalSerial Interface), DMX (Digital Multiplex), and KNX (based systems),wired Ethernet, etc.

FIG. 1 illustrates, schematically, a network 1 of communicativelyinterconnected network node devices or client devices or in short nodesor clients 3, 4, 5, 6, 7, 8 and a gateway device 2 comprising a serveror processor 19 for upgrade or update of software data of clientdevices. The network 1 is configured as a so-called Wireless MeshNetwork, WMN, also commonly called Wireless Personal Area Network, WPAN,in accordance with the ZigBee protocol.

The network 1 is comprised of multiple network end nodes or clients 3,5, 8 and network relay nodes or clients 4, 6 such as bridges andswitches, for example. The nodes or clients 3-8 may form part ofelectric or electronic networked devices. The wireless communicationconnections between the network devices 2-8 are indicated by dashedarrows 9. Those skilled in the art will appreciate that in a generalnetwork architecture, part of the node or client devices may alsoconnect by wired communication links (not shown).

The network end nodes or clients 3, 5, 8 are generic for supporting datacommunication of a large variety of electric or electronic devices,either mobile or movable devices and/or non-mobile or stationarydevices. Examples of such devices are lighting devices, in particularsmart lighting devices comprising Light Emitting Diode, LED, lightingmodules, smart equipment for mobile telephony and data communication,Customer Premises Equipment, CPE, and so-called Internet of Things, IoT,devices.

Reference numerals 12-16 designate devices or systems, such as sensorsfor measuring humidity, temperature, Infra Red, IR, radiation, CarbonMonoxide, Carbon Dioxide, generally designated CON, actuators, camerasystems, alarm systems, and other smart equipment running softwareapplications. In the embodiment shown, the devices 12, 15 and 16 connectby a wired connection 17 to a respective node or client device, whereasthe devices 13 and 14 connect by a wireless connection 18 to arespective node or client device, indicated by dash-dot lines. It willbe appreciated that the devices 12-16 may be external of or internal,i.e. integrated in a network node or client device. In the presentembodiment, data exchange over the connections 17 and 18 is also inaccordance with the ZigBee protocol. Network relay nodes or clients 4, 6may bridge a communication distance between neighbouring network endnodes or clients 3, 5 or 5, 8 if such end nodes or clients 3, 5, 8 arenot capable of establishing a direct communication connection betweenthese end nodes. It is noted that network relay nodes or clients 4, 6besides extending the network range, may also support supplementary datacommunication of a same variety of electric or electronic devices asmentioned above in connection with the end nodes or clients 3, 5, 8.Further, an end node or client and a relay node or client may becomprised in a single physical device. A node or client device may bemains or battery operated, for example.

The gateway device 2 operates as a network control or coordinatordevice, which may provide access 11 to other networks, such as theInternet 10, for example. Such a network control or coordinator deviceis also called a network access device. The gateway device 2 may bedeployed in the network 1 or remote of the network 1. For communicationpurposes, the gateway 2 may comprise integrated transceiver equipment,that may directly connect to a data processing part of the gateway 2,for example by a universal serial bus, USB, port or the like, andcomprises communication functionality for exchanging data packets ormessages with the network nodes or clients in the network 1 using a sameprotocol as the network node or client devices 3-8, i.e. in the presentexample the ZigBee communication protocol.

Smart electric or electronic devices, such as smart lighting devices ina ZigBee network, for example, usually have embedded software inside andoften need to upgrade or update their software for several times duringtheir whole life cycle. When these devices are installed in end users'sites, the most convenient way to upgrade or update them is to performover-the-air, OTA, data upgrade or update via the node or client devices3-8 in the network 1. To this end, in the embodiment shown, the gatewaydevice 2 comprises an OTA server or processor 19 for upgrade or updateof software data of client devices. Those skilled in the art willappreciate that the OTA server 19 may also reside external of thegateway device 2, for example in the Internet or data ‘Cloud’ 10, or mayoperate as a separate OTA server node or OTA server gateway device inthe network 1.

The network node or client devices 3-8 may communicate 9 directly withthe gateway device 2 or, as described above, messages or data packetsmay be relayed to the gateway device 2 via neighbouring network relaynodes or clients 4 in the mesh network 1. The network node or clientdevices 3-8 are further configured for exchanging data messages or datapackets with one or a plurality of the node or client devices in theirneighbourhood.

Messages that are generated in a network node or client 3-8, andforwarded to the gateway 2 are generally referred to as uplink messagesor uplink traffic. Messages that are forwarded from the gateway 2 to anetwork node or client 3-8 are referred to as downlink messages ordownlink traffic. When not explicitly mentioned, the node or clientdevices 3-8 and the gateway device 2 are arranged for communicatingmessages or data packets in the network 1 of the present disclosure ineither one or both of a unicast and broadcast transmission mode.

FIG. 2 illustrates, in a sequence diagram 20, an example of a method ofinquiring a node or client device address announce message by a gatewaydevice at commissioning of the network in accordance with the ZigBeespecification, issued by the ZigBee Standards Organization, which ZigBeespecification is herein fully incorporated by reference.

For clarity reasons, only three node devices 3, 4, 5 are shown in thesequence diagram.

In FIG. 2, time is running from the top to the bottom of the sheet (notshown). In this example, after commissioning of the network 1, that isafter installation and testing of the node devices and the gatewayequipment and communication facilities of the network according todesign objectives or specifications, the gateway device 2 broadcasts aninquiry message, M_(INQ), or inquiry data packet 21 in the network 1.The inquiry message 21 is directly received by the end node or clientdevice 3 and the relay node or client device 4, and is indirectlyreceived by the end node or client device 5 through the network relaynode or client device 4, for example. This inquiry message 21 may bebroadcasted after a certain time interval after starting or endingcommissioning of the network. For example, the inquiry message 21 may bebroadcasted after a time interval of 15 minutes after endingcommissioning of the network 1.

Receipt of the inquiry message 21 commands or causes the node or clientdevices in the network to announce their address information. Thegateway device 2 may need to know any or both of the specific networkaddress and/or Media Access Control, MAC, address or IEEE address of allnode devices in the network in order to correctly control andcommunicate with these node devices.

Each node or client device transmits, i.e. in a broadcast or unicasttransmission mode, its node device address announce message, M_(ANN), oraddress announce data packet 22, 23, 24 in the network 1 for receipt bythe gateway device 2.

The node device address announce messages 22, 23, 24 comprise networkaddress information of the respective node or client device in thenetwork 1 for communication and control purposes, such a specific orshort network address in ZigBee and/or the MAC address allocated to therespective node device.

In a ZigBee enabled network, for example, when a node or client aftercommissioning changes its network address, such as for example the nodeor client device 5, this node or client transmits its new or currentnetwork address in a node device announce packet or message, such asillustrated in dotted lines by reference numeral 25.

The thus gathered network address information by the gateway device 2 ismade available to the OTA servers 19.

Generally, in case of an OTA upgrade, the network devices that requireupgrade or update are called client devices. In the present descriptionand the claims, the term node device or in short node and client deviceor in short client are generic for all the devices connected in a WMN, aWPAN, or any network of communicatively interconnected communicationdevices.

FIG. 3 illustrates, in a sequence diagram 30, an example of a so-calledfast OTA upgrade in accordance with the ZigBee protocol. For clarityreasons, only two node devices 3 and 5 are shown, while time is runningfrom the top to the bottom of the sheet (not shown).

Generally, prior to the start of an OTA, the OTA server 19 builds an OTAlist. The OTA list comprises the network addresses of all candidate OTAclients that may require upgrade or update. Assume that software in thenodes or clients 3 and 5, or any of the devices 14 and/or 16 connectedto the node devices 5, 3, respectively, is to be upgraded or updated.The network 1 as such is indicated by a separate box in the sequencediagram 30.

In a first stage of the OTA upgrade, all candidate clients in thenetwork are informed of the upgrade in that the server 19, if applicablethrough the gateway device 2, broadcasts a notification message 32ImageNotify(broadcast) in the network 1, to notify all candidate OTAclients that an OTA is going to start, reference numeral 31 Stage 1inform all nodes.

Transmission of data packets or data blocks by the OTA starts in stage 2of the OTA upgrade, reference numeral 33 Stage 2 Start download to firstnode in list, in that the OTA server 19 selects a first OTA client inthe list of candidates, say OTA client 3, by transmitting in unicastmode a notification message based on the network address of this OTAclient, reference numeral 34 ImageNotify(client3Address, unicast).

After receiving the notification message 34, the addressed OTA client 3requests by a unicast message data from the OTA server 19, referencenumeral 35 ImageBlockRequest(unicast) and the OTA server 19 replies therequest in broadcast mode with data blocks or data packages comprisingthe upgrade or update information, reference numeral 36 ImageBlockResponse(broadcast). The OTA data blocks or packages are exchangedin a broadcast mode of operation, such that all other OTA clients canreceive them too.

Once the OTA client 3 has received all the upgrade or update data, block37 All data received, the OTA client 3 transmits in unicast mode amessage 38 UpgradeEndRequest(unicast), informing the OTA server 19 thatthe OTA client 3 has received all data of the upgrade file. The OTAserver 19 acknowledges completion of the upgrade to this OTA client 3 inunicast mode by a completion message 39 UpgradeEndResponse(unicast).

Next, in stage 3 of the OTA upgrade, reference numeral 40 Stage 3download to al other nodes in the list, other clients in the upgradecandidate list are selected by the OTA server 19 to check the completionof the upgrade for these nodes or clients. In the present example, theOTA server 19 transmits in unicast mode a respective notificationmessage 41 to OTA client 5 ImageNotify(client5Address, unicast). BecauseOTA client 5 may have received already many data blocks or data packetsfrom the previous broadcast of the upgrade data or update data by theOTA server 19 to the OTA client 3, the OTA client 5 now only may requestpossible missing data blocks or data packets from the OTA server 19.

If data blocks are missing, the OTA client 5, in response to thenotification message 41 transmits in unicast mode to the server 19 arespective data request message 42 ImageBIockRequest(unicast) and theOTA server 19 replies the request in broadcast mode with data blocks ordata packages comprising the missing upgrade or update information,reference numeral 43 Image BlockResponse (broadcast). The missing OTAdata blocks or packages are exchanged in a broadcast mode of operation,such that all other OTA clients can receive them too.

During the OTA upgrade, the OTA client 5 and the OTA server 19 mayexchange several data request and data response messages 42, 43.

If the OTA client 5 has received al missing upgrade data packets or datablocks, reference numeral 44 All missing data received, the upgrade forthis OTA client 5 is ended by the exchange of message 45UpgradeEndRequest(unicast), from the OTA client 5 to the OTA server 19and OTA completion message 46 UpgradeEndResponse(unicast), from the OTAserver 19 to the OTA client 5. Both messages are exchanged in unicasttransmission mode.

If OTA client 5 has no missing data blocks, it will immediately transmitthe UpgradeEndRequest(unicast) message 45 in response to thenotification message 41, informing the OTA server 19 that the OTA client5 has received all data of the upgrade file, and the upgrade to this OTAclient may be completed by the OTA server 19 in responding with anUpgradeEndResponse(unicast) message 46.

The OTA server 19 repeats the transmission of a notification messageaddressed to all other candidate OTA clients from the upgrade list, oneafter the other, till the OTA server has received completion messagesfrom all OTA clients informing the OTA server that all OTA clients havereceived the upgrade file, and the upgrade to all the OTA clients may becompleted.

As mentioned above, during an ongoing upgrade, that is started with thebuilding of the list of candidate OTA clients by the OTA server, an OTAclient's network address, such as the ZigBee short address, may getchanged. Such a network address change may be caused, for example, ifthere is any address conflict between two node devices in a largenetwork, for example when a new device is added to the network.

After the client's network address changes, the client may broadcast itsnew or current network address in the network, such as with a deviceannounce packet or message, as mentioned above in respect of thecommissioning of the network and its devices. However, in particular inlarge scale networks, the OTA server may not receive the message.Whether the new address is broadcasted by a device may dependent on thecommunication protocol used. In practice, the OTA server may be leftunknown of the new network address during an ongoing OTA upgrade.

FIG. 4 illustrates in a sequence diagram 50 an example wherein OTAclient 5 exhibits a network address change in stage 3 of the OTA upgradeor update process, and the OTA server 19 is not informed of this networkaddress change. The steps in stages 1 and 2 of the OTA upgrade areidentical to steps as disclosed above with reference to FIG. 4, and arefor convenience sake indicated by single double arrows 32 and 34-39,respectively.

In this example, it is assumed that the network address change of OTAclient 5 occurs after the OTA server 19, in stage 3 of the OTA upgradeprocess, has already replied to an ImageBIockRequest(unicast) 42 of OTAclient 5 by the transmission of OTA upgrade data in a ImageBlockResponse(broadcast) 43.

As a consequence of the network address change, the OTA client 5 mayrequest anew for upgrade data with the OTA server 19, by transmitting tothe OTA server 19, in unicast mode, anImageBIockRequest(current-netw-address) 52, based on the current. i.e.the new network address of the OTA client 5.

As the network address in the data request message 52 does not match thenetwork address of the OTA upgrade notification message 41 previouslytransmitted by the OTA server 19, the OTA server 19 will not recognizedata request message 52 as a request in the ongoing OTA upgrade with OTAclient 5, and will drop this data request, as indicated by referencenumeral 53, DroplmageBlockRequest.

The OTA client 5 may, after lapse of a time interval, repeat ones orseveral times the ImageBIockRequest(current-netw-address) 52.

As the OTA server 19 will drop any message received with the currentnetwork address of the OTA client 5 in the ongoing OTA upgrade,eventually the OTA server 19 will assume not to receive a response fromthe OTA client 5, such that a timeout at the OTA server 19 occurs, asindicated by reference numeral 54 Timeout of OTA Upgrade OTA client 5,and the OTA upgrade process fails, because the OTA server 19 and the OTAclient 5 are not able to communicate with each other anymore.

In accordance with the present disclosure, in case of a timeout, the OTAserver 19 checks the network or short address change with the OTA client5 in a reliable way by transmitting, for example in a broadcast mode ofoperation, a network address querying message 55 Query Network Address(broadcast) in the network 1. The broadcasting can be repeated forseveral times, to make sure that the OTA client 5 will receive it. Thenetwork address querying message 55 may be based or comprise the MediaAccess Control, MAC, address or IEEE address of node or client device 5,or any other identifier uniquely identifying the OTA client 5 in thenetwork 1.

Once the network address querying message 55 is received by the OTAclient 5, the OTA client replies this message by reporting its currentor new network address to the OTA server in a network address reportingmessage 56 Report current network address (unicast), preferablytransmitted in unicast mode. At receipt of the changed network addressof OTA client 5 at the OTA server 19, the OTA upgrade process with OTAclient 5 will be continued by transmitting, by the OTA server 19, arespective notification message 41 ImageNotify(client5Address, unicast).In this message client5Address is the new network address or shortaddress of OTA client 5. The OTA upgrade then continues as describedabove with reference to FIG. 4, stage 3, and for convenience indicatedin FIG. 4 with a double arrow 41-46.

The sequence diagram 60 in FIG. 5 illustrates an other example whereinthe OTA server 19 may cause a timeout in case of a network addresschange of an OTA client device in an ongoing OTA upgrade process. Again,it is assumed that the OTA server will or has not been informed about achange of the network address of OTA client 5. In this example, thenetwork address change at OTA client 5 occurs at the start of stage 3,prior to the transmission of a notification message to OTA client 5 torequest possible missing upgrade data blocks or data packets from theOTA server 19, as indicated by reference numeral 61 Network addresschange.

The OTA server transmits the notification message 41 in unicast modebased on the old or previous network address of OTA client 5ImageNotify(old client5Address, unicast). The OTA client device 5 willnot receive the OTA upgrade notification message 41 transmitted by theOTA server 19, because the network address of this message does notmatch the current or new network address of OTA client 5. Accordingly,the OTA client device 5 will not respond to the notification message byrequesting the server to transmit the missing data of the OTA upgrade.The notification message 41 may be repeated a few times by the OTAserver 19. As no request for upgrade data will be received by the OTAserver 19, eventually a timeout 62 occurs at the server 19, Timeoutwaiting for ImageBlockRequest.

In accordance with the present disclosure, in case of a timeout, the OTAserver 19 checks the network or short address change with the OTA client5 by transmitting a network address querying message 63 Query NetworkAddress (broadcast) in the network 1. The network address queryingmessage 63 is based or comprises the Media Access Control, MAC, addressor IEEE address of node or client device 5, or any other identifieruniquely identifying the OTA client 5 in the network 1.

Once the network address querying message 63 is received by the OTAclient 5, the OTA client replies this message by reporting its currentor new network address to the OTA server 19 in a network addressreporting message 64

Report current network address (unicast), preferably transmitted inunicast mode. At receipt of the changed network address of OTA client 5at the OTA server 19, the OTA upgrade process with OTA client 5 will becontinued by transmitting, by the OTA server 19, a respectivenotification message 41 etcetera, as disclosed above with reference toFIGS. 3 and 4, and generally indicated in FIG. 5 with a double arrow41-46.

Although not explicitly shown, those skilled in the art will appreciatethat a timeout at the OTA server 19 may also occur when a change ofnetwork address occurs in an OTA client prior to the transmission of theUpgradeEndRequest(unicast) 45 by the OTA client. Further, a servertimeout may also occur if an OTA client changes network address at stage1 or during stage 2 of an ongoing OTA upgrade or update.

The network address querying message 55, 63 may be repeated by the OTAserver until a set or settable maximum number of repeats is exceeded,for example. In that case, the OTA upgrade may be started anew or anetwork address inquiry process may be started as illustrated withreference to FIG. 2, for example.

FIG. 6 shows, for completeness sake, in a sequence diagram 65 acomprehensive example of a known fast OTA upgrade in a ZigBee enabledcommunication network 1, of an MQTT (Message Queuing TelemetryTransport) protocol 67 MqttUpdateProtocol available from an externalsource connected to the Internet or Cloud 10. MQTT is amachine-to-machine (M2M)/Internet of Things connectivity protocol and isused, for example, with sensors connected in ZigBee enabledcommunication environment. This protocol is also applicable with mobileapplications because of its small size, low power usage, minimised datapackets, and efficient distribution of information to one or manyreceivers. Reference is also made to FIG. 1.

In a first step, collectively identified by reference numeral 70, theupdate or upgrade file is downloaded from a backend device in the cloud10, indicated by reference numeral 68 UpdateProtocol. As alreadydisclosed above, a list of candidate node devices or client devices tobe updated is retrieved from a database 69, for example available in thegateway 2 or OTA server 19. The OTA upgrade is performed under controlof the OTA server 19.

In the first stage, i.e. stage 1, of the OTA upgrade, all nodes orclients to be updated, i.e. 3, 5, 8 or node1, node2, node3,respectively, are informed of the commencement of the OTA upgrade,collectively identified by reference numeral 71.

Next, in stage 2, for the first node or client in the candidate upgradelist, upgrade data packets or data blocks are broadcasted by the OTAserver 19, till the upgrade of this node or client 3 is completed.Upgrade status information is exchanged between the OTA server 19 andthe cloud based update source 10. The steps of notifying, querying forand providing upgrade data are collectively referred to by referencenumeral 72.

At stage 3 all the other nodes or clients 5, 8 are one after the otherchecked for update, as collectively indicated by reference numeral 74,and in this stage also upgrade status information is exchanged.

The sequence diagram 75 in FIG. 7 illustrates an example of a reset orpower interruption 76 Reset/power interrupt of client 5 at stage 3 ofthe OTA upgrade. As described above, in stage 2 of the OTA upgrade, theclient 5 has already received data packets or data blocks broadcasted bythe OTA server 19 during the upgrade or update of client 3. In stage 3of the fast OTA upgrade, only data packets that client 3 is missing arebroadcasted by the OTA server 19.

However, if the reset or power interruption 76 has the consequence thatthe upgrade data packets already gathered by client 5 are lost, thewhole fast OTA upgrade will be delayed, as this OTA client will performan OTA upgrade from the start, inclusive the exchange of the datapackets already broadcasted at stage 2 of the IOTA process.

Eventually, an OTA upgrade failure may also arise from a client or nodereset or power outage during an ongoing OTA upgrade, for example if theOTA server 19 does not receive a response from the (disabled) client 5after transmission of the notification that the OTA server 19 isavailable for upgrade of node 5 by a ImageNotify(client5Address,unicast) message 41, and eventually times out. See also FIG. 4.

Those skilled in the art will appreciate that a timeout of the OTAserver 19 disclosed above in connection with FIG. 5 is also applicablein case of reset or power outage for a longer time. In that case, inaccordance with the present disclosure, the OTA server 19 may quicklyresume the OTA update or update through a network address queryingmessage from the OTA server 19 and a network address reporting messagefrom the client 5, as the network address of the client 5 is generallynot changed. Even if the network address of the client 5 would have beenchanged due to a device reset, the OTA upgrade may continue with thesolution according to the present disclosure, as disclosed by the doublearrow labelled 55-56, 63-64 in FIG. 7, and continue with the download ofmissing packets, as indicated by the double arrow 41-46.

To avoid loss of already stored data packets at a node device or client,it is proposed to make sure that the client or node during fast OTA willpersistently record the data packages or image received and OTA statusor stage information. If any reset or power outage happens, the node orclient may resume to continue the fast OTA process, i.e. steps 41-46,without any data loss. This will significantly reduce the total upgradetime of the whole network.

Persistent data storage support may be achieved by a non-volatile memoryor storage, such as Serial Peripheral Interface, SPI, flash memory orother external flash accessible to the OTA client device. OTA status orstage information is kept in an OTA state machine of the OTA clientdevice.

FIG. 8 shows, in a flow chart type diagram 80, an algorithm for resumingOTA upgrade after a client or node device resets or restarts in the caseof a non-volatile storage of received data packets and OTA statusinformation at the node or client device. In the flow chart 80, thenormal flow of operation runs from the top to the bottom of the sheet.In all other cases, an arrow indicates the flow direction.

After a device or OTA client restart, block 81 ‘Device restart’, an OTArestore and OTA state check is performed by the OTA client. That is, thefast OTA stage or status in which the OTA client existed prior to thereset or restart is checked, decision block 82 ‘OTA restore check, OTAstate exists ? If their exists an OTA state of the OTA client, that isthe OTA client was involved in an ongoing OTA upgrade, i.e. decisionblock 81 result ‘Yes’, the OTA client state machine and the alreadyreceived data packets of the ongoing OTA upgrade should be restored,i.e. block 83 ‘restore OTA state machine and data’. The OTA upgrade isresumed by checking whether OTA upgrade data packets are received, i.e.decision block 86 ‘Receiving OTA packet ?’.

If no OTA state exists, i.e. decision block 81 result ‘No’, the OTAupgrade process is resumed at the OTA client by checking for the receiptof a notification message of the OTA server 19 to start requesting OTAupgrade data packets by the OTA client, i.e. decision block 84‘Receiving image notify ?’. If negative, i.e. decision block 84 result‘No’, the client device keeps checking. In the affirmative, i.e.decision block 84 result ‘Yes’, the client OTA information and statemachine is saved, i.e. block 85 ‘Save OTA information and statemachine’, and OTA upgrade data packets are received by the OTA clientand stored, i.e. decision block 86 result ‘Yes’ and block 87 ‘Savereceived packet in flash’. That is, in this embodiment, the received OTAupgrade data are stored in flash memory and the index as well isrecorded.

If no OTA data packet is received, i.e. decision block 86 result ‘No’,the client device keeps in a mode for receiving OTA upgrade or updatedata packets, and also as long as not all OTA data are received, i.e.decision block 88 ‘OTA packets finished ?’, result ‘No’.

If OTA packets are complete, i.e. decision block 88 result ‘Yes’, theOTA procedure is stopped, as illustrated in FIGS. 4 and 6, for example,i.e. block 89 ‘End of fast OTA’.

Accordingly, with the above reset-restore algorithm, during the OTAstate, if the node is reset or power down/on, the OTA process willcontinue and does not need to receive all the upgrade packets from thebeginning. This significantly reduces the total time to upgrade all thenodes or clients in the network also if any power cut event occurs atone or more of the client devices selected for update or upgrade.

FIG. 9 illustrates, schematically, a circuit diagram of an embodiment ofa server device 90 arranged for performing OTA upgrade or update ofclient devices in a mesh network or the like, in accordance with thepresent disclosure. The server 90 comprises a transceiver, Tx/Rx, module91 arranged for wireless 92, i.e. over-the-air, exchange of messages ordata packets in the network. The transceiver 91 is further arranged forwired data exchange with an external device, such as a backend server inthe Internet or cloud 10 (FIG. 1), through an input/output data terminal94. The transceiver 91 may be configured to operate in accordance withany of the data communication technologies and protocols mentioned abovewith reference to FIG. 1, in one or both of a broadcast and unicast modeof operation and, if applicable, for data exchange with external sourcesin other networks, such as the Internet, for example.

The server device 90 further comprises at least one data processor orcontroller 95, and at least one data repository or storage or memory 96,among others for storing computer program code instructions which, whenloaded and run on to the one or more processor or controller 95,configure the server device to operate in accordance with the method ofthe present disclosure.

Upgrade data for the clients in the network may be stored in therepository 96, or a separate memory or storage accessible to the atleast one processor or controller 95. The at least one processor orcontroller 95 communicatively interacts with and controls thetransceiver 91 and the at least one repository or storage 96 via aninternal data communication bus 98 of the server device 90.

Although not explicitly shown in FIG. 9, a dongle may connect to the bus98 for performing address inquiry processing in accordance with thepresent disclosure. In practice, the server 90 may form part of agateway device 2, as shown in FIG. 1.

FIG. 10 illustrates, schematically, a circuit diagram of an embodimentof a node or client device in accordance with the present disclosure.The node device 100 comprises a transceiver, Tx/Rx, module 101 arrangedfor a wireless 102 and/or wired 103 exchange of messages or data packetswith a gateway and/or over-the-air upgrade server, and other nodedevices, inclusive relay node devices, in a network of communicativelyinterconnected network node devices. The transceiver 101 may beconfigured to operate in accordance with any of the data communicationtechnologies and protocols mentioned above with reference to FIG. 1, inone or both of a broadcast and unicast mode of operation.

The node device 100 further comprises at least one data processor orcontroller 105, and at least one data repository or storage or memory106, among others for storing computer program code instructions which,when loaded and run on to the one or more processor or controller 105,configure the node device 100 to operate in accordance with the presentdisclosure. Address information 107 of the node device in a network,inclusive its MAC address, may be stored in the repository 106, or aseparate memory or storage accessible to the at least one processor orcontroller 105.

The repository or storage 106 further may be arranged as a persistent orprogrammable erasable storage for storing upgrade data packets and stateinformation of an ongoing OTA process. To this end the data repositoryor storage 106 may be arranged as a non-volatile memory or storage, suchas Serial Peripheral Interface, SPI, flash memory or other externalflash accessible to the OTA client device. OTA status or stageinformation may also be kept in an OTA state machine 108 residing in theprocessor or controller 105 of the OTA client device 100, for example.

The at least one processor or controller 105 communicatively interactswith and controls the transceiver 101 and the at least one repository orstorage 106 via an internal data communication bus 109 of the node orclient device 100.

The node or client device 100 may be part of or operatively connect 104to an electric or electronic device, such as lighting device 110,comprising a lighting module 111, preferably a LED lighting module,operation of which may be controlled by the node device 100 from orthrough a network gateway, or by a remote control device, for example.As mentioned above, instead of or in addition to a lighting device, anode device may control several other electric or electronic devices,operatively connected in a network in accordance with the presentdisclosure.

The present disclosure proposes to let the OTA server check whether anetwork address change of a selected OTA client causes the OTA server totimeout waiting for a response or request message from an OTA clientduring an ongoing OTA data upgrade. Instead of dropping a request fortransmitting OTA upgrade by the OTA server based on the changed networkaddress of an OTA client, i.e. dropping 53 theImageBlockRequest(current_netw_address) 43 in FIG. 4, it is possible tobroadcast, by the OTA server, as a network address querying message, anImageBlockResponse with a specific status value that informs the OTAclient to report its current network address to the OTA server. The OTAserver, when receiving a request from an unknown device, i.e. a devicethe network address of which is unknown to the OTA server, an ABORTstatus may be transmitted by the OTA server in response. Alternatively,upon a network address change in a ZigBee enabled network, the OTAclient selected by the OTA server for OTA upgrade may re-broadcast thedevice announce message Device_annce upon a failing request fortransmitting OTA upgrade, i.e. an Image request, for a several times.The OTA client changing the address may also include for a while itsIEEE address in the NWK header after an address change. According to theZigBee specification, for example, upon receipt of a frame containing a64-bit IEEE address, the contents of the nwkAddressMap and NeighborTable should be checked for consistency, and updated if necessary. TheOTA client changing the address could also unicast the device announcemessage Device_annce or APS Device Update command to the OTA server—inaddition to the broadcasted Device_annce message. This to overcome theabove-mentioned problem that a broadcast from the OTA client may notreach the OTA server. Unicast from the client, used for ImageBlockrequest, seems to be assumed to be working reliably.

Further, the requirement on the OTA server to drop an Image requestcommand arriving from an unknown network or short address may be relaxed(after timeout). This may allow the OTA server to recover from thecurrent problem by just accepting the new networks address of the OTAclient device in the ongoing OTA upgrade. This may also be applied whenthe OTA client getting unpowered or loosing connection in the middle ofthe update, as the other clients may also track the timeout and, basedon an selection algorithm, send the Image Request instead.

In the case of an OTA client power outage or reset during an ongoing OTAupgrade of an OTA client selected by the OTA server and if that OTAclient is not operating for a longer time, the OTA server may selectanother client for upgrade, and preferably starting where the OTA serverleft off with the rebooting client. The rebooting device, when again inoperation, could still restore the blocks and continue collecting theincoming packets.

In addition, if it is the OTA server that gets power-cycled in themiddle of the OTA exchange, same may store persistently any informationrelating to the ongoing ITA upgrade, such as the network address of thecurrent OTA client, the data blocks or data packets transmitted,etcetera.

Although not explicitly described above, OTA upgrade or update datablocks or data packets exchanged by the OTA server may comprise a blockor packet number or identification and an identification of the totalnumber of data blocks or data packets in a particular OTA upgrade.

It is noted that the above apparatuses may be implemented based ondiscrete hardware circuitries with discrete hardware components,integrated chips, or arrangements of chip modules, or based on signalprocessing devices or chips controlled by software routines or programsstored in memories, written on a computer readable media, or downloadedfrom a network, such as the Internet.

It shall be understood that the apparatus, the commissioning and/orcontrol device, a luminaire device, a lighting system, the method, andthe computer program product of the above aspects may have similarand/or identical preferred embodiments, in particular, as defined in thedependent claims.

It shall be understood that a preferred embodiment of the invention canalso be any combination of the dependent claims or above embodimentswith the respective independent claim.

1. A method of performing an over-the-air, OTA, upgrade by a server in anetwork of communicatively interconnected client devices, wherein saidserver transmits a network address querying message if an ongoing OTAupgrade of a client device causes a timeout at said server, and whereinsaid server resumes said OTA upgrade of said client device after saidserver receives a network address reporting message of said clientdevice comprising its current network address.
 2. The method accordingto claim 1, wherein said network address querying message comprising aMedia Access Control, MAC, address of said client device.
 3. The methodaccording to claim 2, wherein said network address querying message isbroadcasted by said server in said network.
 4. The method according toclaim 1, wherein said server causing said timeout from a failure toreceive a request for transmitting OTA upgrade data from a client deviceafter transmitting an OTA upgrade notification message notifying saidOTA upgrade to said client device.
 5. The method according to claim 1,wherein said server causing said timeout from receiving a request fortransmitting OTA upgrade data from a client device comprising a networkaddress that does not match a network address of an OTA upgradenotification message transmitted by said server notifying said OTAupgrade to said client device.
 6. The method according to claim 1,wherein said network address querying message is repeated by said serveruntil a maximum number of repeats is exceeded.
 7. The method accordingto claim 1, wherein said server resumes said OTA upgrade of said clientdevice by transmitting, based on said received current network addressof said client device, an OTA upgrade notification message notifyingsaid OTA upgrade to said client device.
 8. The method according to claim7, wherein said OTA upgrade notification message, based on said receivedcurrent network address of said client device, is transmitted in unicastmode from said server to said client device.
 9. A method of performingan over-the-air, OTA, upgrade by a client device from a server in anetwork of communicatively interconnected client devices, wherein in anongoing OTA upgrade said client device transmits a network addressreporting message comprising its current network address in response toreceipt of a network address querying message from said server.
 10. Themethod according to claim 9, wherein said network address reportingmessage is repeated by said client device until a maximum number ofrepeats is exceeded.
 11. The method according to claim 9, wherein aclient device records received OTA upgrade data packages and a currentOTA upgrade status in a non-volatile storage, and wherein said clientdevice resumes said OTA upgrade after receipt of an OTA upgradenotification message from said server notifying said OTA upgrade to saidclient device.
 12. A server, arranged for performing an over-the-air,OTA, upgrade in a network of communicatively interconnected clientdevices in accordance with the method of claim
 9. 13. A client device,arranged for performing an over-the-air, OTA, upgrade in a network ofcommunicatively interconnected client devices in accordance with themethod of claim
 9. 14. A computer readable computer program product,comprising computer program code instructions which, when run on acomputer device, causes said computer device to perform the method ofclaim
 1. 15. An electric or electronic device, such as a lightingdevice, comprising a client device according to claim 13.